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Smoothing Digital Inputs 

There's a lot of way ways to debounce digital inputs. A few are listed in this article. 
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The gurus of analog electronics sometimes wax poetic about the beauty of their crea 
It's not unusual to see a beatific smile crossing their faces as they tune a feedback lo< 
tweak the last little bit of stability into amplifier. Personally, I detest the analog worl 
so full of, well, reality. The analog world is full of noise and oscillation, component; 
degrade as they age, and all the other problems that seem unrelated to making a lous 
circuit work. 

Once, I thought computers were immune to these problems. Now we're all fiddling > 
digital phase locked loops that don't lock and high speed circuits that make even the 
simplest computer an RF nightmare. Even well designed digital circuits are subject 1 
noise effects. Noise makes analog designers old and grey. It can have the same effec 
the unwary firmware engineer. 

Our realm is the world of ones and zeroes. There are no half levels (at least not for 1< 
the computer will make a binary decision about any input applied to it). This does n< 
mean, however, that the logic 1 your code just read from some peripheral really mea 
device is supplying a one. 
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Some time ago I put a measurement system in a steel mill. Like many big industrial 
processes, steel making creates a staggering amount of electromagnetic interference. 
1000 foot line consisted of perhaps 400 huge rollers, each weighing several tons, an< 
equipped with a 10 horsepower motor. The motors drove a steel plate back and forth 
reversing direction every few seconds. The EMF generated during a direction revers 
enough to induce several volts of signal on even a simple unconnected voltmeter. Oi 
sensors brought 20 to 1 00 volts of induced spikes back to the computer room on thei 
cabling. Despite careful differential design, erratic values from these digital inputs v 
uncommon. 

It's generally pretty safe to assume that digital signals generated locally to the embec 
controller are clean and free from noise-induced transients. Any input, whether digit 
analog, that comes over a long cable should be looked at suspiciously. If the signal 
changes to a random value occasionally, will it wreak havoc in your product? 

Noise 

What exactly is noise? Analogers consider any unwanted signal alteration a form of 
though generally noise is defined as that part of the input originating from somethin; 
than the sensor. For example, cosmic background radiation was discovered by engin 
working for the phone company, who found interference no matter which way they 
oriented their antennas. Very recently the Cosmic Background Explorer satellite ma 
this radiation and found compelling evidence supporting the big bang theory of 
cosmology. 

Digital noise is the same thing. Given a 1 from the sensor, the signal is noise-free if 
computer always reads that value as a one. If once in a hundred readings the firmwa 
interprets the signal as a zero, then the channel is not noiseless, so either the code or 
electronics will need some tuning to correct the problem. 

Mechanical contacts used as computer inputs are a prime source of "noise", though 1 
noise is referred to as "bounce". A switch or relay contact literally chatters for quite 
milleseconds when it closes. That is, pressing a switch will send a random stream of 
and zeroes to the computer for a long time. 

Sometimes pure digital signals are transmitted through slip rings. For example, a rac 
antenna rotates continuously in one direction - it's impossible to wire directly to the 
sometimes complex circuits on the antenna, as a cable would quickly twist itself all 
the motor and supporting structure. Slip rings are brushes that rub on an insulated sh 
transmitting data or power though the rubbing contact. Slip rings, especially when d 
generate all sorts of interesting modifications to the signals propagated though them 

Another form of "noise" is signal corruption due to limits in the accuracy or depend; 
of the input source. A compact disk supplies a stream of ones and zeroes, but the 
reliability of the data is moderately low - pits and fissures in the medium masquerad 
real data. This problem is so severe significant extra hardware and recording space i 
devoted to error correction codes that can both detect and then correct the flaw. We 
same sort of effect with dynamic RAMs - every PC in the world uses 9 bits instead ( 
each byte of storage, encoding parity information in one position. Again, the problei 
severe (though memory does seem super reliable now) that the cost of a lot of extra 
hardware is justified. 
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It is pretty common to see error detection bits appended to nearly all serial communi 
schemes. Few simple parallel input bits get the same sort of treatment. Is this becaus 
application can tolerate errors? Or, have the designers merely forgotten to question t 
basic assumptions? Remember: nature is perverse, and will endeavor to cause maxir 
pain at the worst time. If there is any chance that your encoder or switch inputs coul 
become garbled occasionally, then be awfully sure your code can deal with the prob 

Hardware Solutions 

To my knowledge, there are only three ways a hardware designer can deal with nois 
digital inputs. The first is to use the best possible practices for transmitting signal. T 
includes routing signal wires away from noise-inducing high current cables, adding 
shielding where necessary, and using the proper transmission techniques. A fiber op 
link is immune from induced EMF and is an ideal solution. 

A lot of folks assume differential transmitters and receivers provide foolproof transr 
in any environment. The theory is that both the positive and negative signals (the da 
send on a pair of wires, with a positive and inverted version on each wire) will have 
same signal induced. This is called "common mode", since a common corruption ap 
on each wire. The receiver compares the wires and removes this common mode, hof 
giving a nice clean version of the input. Differential transmission does work very w< 
most of the time, but enough common mode can swamp receivers, and has even bee 
known to destroy the ICs. 

Alternatively, good design practice might dictate replacing noisy sensors with somel 
producing a cleaner output, albeit at a higher price. A Hall-Effect switch, for exampi 
produces bounceless outputs. I'm not advocating giving up switches with mechanica 
contacts, but in some situations it pays to consider alternatives. 

A second hardware solution is to transmit either a correction code, as in the case of; 
or simply a parity bit or hamming code that at least alerts the computer that the byte 
simply cannot be correct. Both are great ideas; both are relatively expensive in print 
circuit board real estate, copper costs, and circuits used. It's pretty rare to see simple 
parallel inputs accompanied by ECC or parity information. 

A third approach adds hardware to the receiving computer to clean up the input. Ab( 
only time you'll see this in switch debouncing applications, where a simple set-reset 
flop removes all switch bounce. The down side is the use of half a 7400 for each sw: 
and the need for double pole switches. 

While on the subject of hardware, I'll get on my anti-NMI soapbox again and ask ev 
to NOT connect NMI, or any other interrupt line for that matter, to a mechanical cor 
The only exception is if you've added a hardware debouncer to the signal. Otherwise 
every bit of bounce will reinitiate the service routine. With NMI one real interrupt w 
masquerade as several independent interrupts, each one pushing on the stack and rec 
the ISR. Maskable interrupts will be serviced on every bounce, needlessly eating up 
valuable CPU time. 

Firmware Fixes 

A lot of systems remove analog noise by averaging the input; this is not really an op 
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for smoothing digital inputs, because a switch can only be on or off; it cannot (excet 
fuzzy logic systems, I suppose) be 50% on. Thus, digital filters always seem to be v< 
algorithms: if 75 of 100 reads of the input sense a logic one, then the code assumes t 
data is indeed a one. 

Other algorithms read and reread until the data settles down. If 75 of 100 reads give 
logic one, then the input is noisy and is resampled until 100 of 100 reads are consisti 

The problem with the trivial implementations is that each requires a lot of elapsed tii 
Take the case of debouncing a switch. The switch is going to bounce practically fort 
perhaps as long as 50-100 msec. Nothing the code can do will eliminate this delay. 
Software that reads and reads and reads until 100 of 100 reads are identical will bun 
time until that inevitable 50-100 msec elapses. 

One way to eliminate this wasteful use of the CPU is to have a timer interrupt the CI 
regularly, read and filter the input(s), and store the result for future use. 

I've always felt the one hardware resource I want to support the software is a timer. 
Programmed to interrupt every 1 to 10 msec, it provides a time base that is very usei 
sequencing tasks and other activities. Digital filtering is a perfect use of the timer, as 
the case of debouncing) a few reads widely separated in time are every bit as good a 
thousand sequential reads. 

Even better than writing a big, complex interrupt service routine that filters the inpu 
use a Real Time Operating System (RTOS). I'll ruefully admit to having rolled my o 
RTOS on more than one occasion. Usually, my homebrewn ones are fairly primitive 
supporting multitasking but little else. I buy DOS, I buy word processors; why write 
own RTOS? 

Tyler Sperry and Gretchen Bay reported on RTOSs in an earlier issue. If you have n 
looked at what a commercially available RTOS brings to the party, by all means get 
vendor literature and look at the rich resources they provide. Multitasking is only a s 
part of the functionality of an RTOS. I'm particularly fascinated by the message pass 
capabilities of these products. 

The OOP movement advocates building brick walls around functions. Keep variable 
to functions, and pass parameters around as messages. It's a religious experience to i 
code written in any language using the messaging philosophy. Global variables, the 
of a lot of problem code, will be non-existent. Each function gets everything it need; 
parameter list. 

A decent RTOS supports all sorts of message passing, including queues, semaphore: 
"messages" - data the RTOS passes between tasks. The RTOS takes care of all of th< 
details of message traffic; your code merely has to issue an RTOS call to send one, < 
issue another call to receive the message. Global variables for intertask communicat 
eliminated, along with the potential for a rogue routine that slyly alters the global an 
screws everything up. 

An RTOS bundled into an embedded system will make debouncing and filtering mu 
cleaner and faster. Use the timer ticks to drive the RTOS and initiate context switchi 
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Then, write the filter as a task that generates a smoothed version of the input into a s 
variable local to the task. If the main line code needs the current smoothed input, it c 
request the task to reply with the data via a message. This keeps the entire filtering c 
and all of it's variables in one well-insulated module. Once debugged, you'll never, € 
have to look at it again. No other task should be able to effect the operation of the fi] 

As an aside, some systems read voltage controlled oscillators (VCOs) and compute 1 
frequency of the signal by counting edges over some period of time. An RTOS is th< 
perfect vehicle for this as well - the rationale and methods are practically the same a 
digital filtering. One task can count edges; another, running at some fixed rate, can r 
the count and scale by the time base. Again, if the result is stored into a static local 
variable, any other activity in the program can request the current frequency without 
forced to wait for the data to be acquired. 

If you do feel compelled to write non-interrupt based filters, be wary of the delay co 
Typically these algorithms (especially debouncing code) do a number of reads, wait 
while, and read some more to see if the input settles down. This makes sense but hai 



Is the delay long enough? How do you know for sure? If that short loop takes only 1 
microseconds, not the millisecond you assumed, will this cause some erroneous reac 
assembly language it's easy to figure the number of T-states in a loop to get a good I 
on the time involved, but a small code change several years hence may disrupt these 
figures. Or, changing CPUs, clock rates, or even the number of wait states on a new 
version of the product will cause similar problems. 

Writing in C is more of a problem. How long does 100 repetitions of a null FOR loo 
anyway? This will change depending on the optimizations, compiler version, and ev 
memory model selected. At the very least use a scope to measure the real delay. 
Preferably, generate delays via an interrupt-driven timer. 



If a switch bounces as it is closed, can we shorten the time to decide if it is on or off 
looking at the relative frequencies of ones and zeroes? It seems to me that as the swi 
starts to settle down we'd see many more ones than zeroes returned. Has anyone exp 
this? Feel free to contact me. 
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